There are many reasons why it may be desirable for a first computing device to receive credential(s), such as a user identification and password, from a second computing device (or vice versa), in order to identify the second device and/or determine access levels and permissions for the second device.
For instance, a host computer may have content to which a client device may wish to request access: This is a fairly common scenario and as illustrated in FIG. 1A, the world of computing devices and types of content that may be requested from various other computing devices is quite diverse, both in terms of media devices and media types. For exemplary purposes only, FIG. 1A illustrates that there are many kinds of media, such as music (MP3s, WMVs, etc.), streaming audio/video, photos (JPEGS, GIFs, etc.), movie files (MOVs, MPEG, etc.), advertisements, broadcast media (Radio, TV, Cable, etc.), graphics data, etc. FIG. 1A also illustrates that there are a variety of devices that render media in some fashion, for some purpose including, but not limited to, televisions, radios, tuners, DVD players, VCRs, digital data storage and/or rendering devices, MP3 players, Smart Display devices, laptops, gaming machines, remote control devices, cell phones, PDAs, digital picture frames, etc. Establishing trust among any two devices in such a system is thus an important problem—to enable secure sharing, among a variety of computing devices, of content or resources of the content hosting device in what becomes a networked trust enclave of devices.
Thus, in order to give access to resource(s) of the first computing device to the second computing device, it is frequently desirable to have the first computing device “trust” something about the second computing device, e.g., for security and/or privacy reasons. One common way to give access is to receive credentials from the requesting device, which when received by the hosting device, act as keys to the lock in the door, thereby establishing trust. It can be appreciated that such credential(s) may be exchanged between two computing devices in any computing environment, e.g., network architectures that include peer-to-peer clients, distributed computing systems, thin-client architectures where application processing occurs mainly on a central server, but can be distributed as well, and as described in more detail below, other networked environments as well.
FIG. 1B illustrates a typical prior art logon between a first computing device (e.g., server S) and a second computing device (e.g., client C) in an exemplary networked environment wherein server S and client C communicate over any network connection NC, whether wired or wireless. An authentication exchange may occur between the two devices for a variety of reasons. In a prototypical scenario, client C wishes to access some resource(s) of the server S, such as applications, content, services, etc., or start a session with the server S. Before allowing access to its applications, content, services, etc., however, server S will require some proof that client C is allowed to access the applications, services, content, etc. of the server S. This may include receiving credentials, such as a user identification and password, from the client C.
Today, for such a scenario, if an external object to a computer S attempts to log into the computer S over network NC, the external object presents credentials for authentication using a standard mechanism known to the client C and server S. A credentials login component delivers the credentials to the server S from client C, and an authentication component on server S allows access to its resources according to the permissions represented by the client C's credentials. Generally, it is a physical user that wants to login, and the credentials are usually remembered by the user herself. The user manually inputs the credentials to the computing device C via an external mechanism, e.g., by entering the credentials at login via an input device such as a keyboard. In other prior art systems, the user may type in the credentials one time and, from that time forth, the credentials may be cached or otherwise stored on client C (e.g., “creds” in FIG. 1B). Regardless, the initial transfer of the credentials to client C happens “out-of-band” of the network NC.
However, if the external object is a machine (i.e., not a physical user) that wishes to login in an automated way, the machine must currently obtain credentials from somewhere and this too is usually transferred “out-of-band” of the network via an out of band mechanism for inputting credentials to client C. As mentioned, the main reason for this is to establish trust between the devices. If client C knows a secret from some external out-of-band source that server S and only server S recognizes, then client C can be assumed to be a trusted user of the network NC for communications exchanges between the devices.
However, where trust is already established between two devices, there are at least two reasons for questioning the security of the above-identified prior art login system: (1) vulnerability to dictionary attack and (2) threat of discovery of credentials stored on the client machine.
With respect to the threat of a dictionary attack, a malicious external object could repeatedly with brute force try every input combination and permutation possible for entering credentials and eventually, over time and due to the law of strong numbers, randomly guess the credentials. To fend off a dictionary attack, credentials can be rotated, i.e., changed, frequently. If the credentials are rotated too frequently, however, the user will have difficulty remembering the credentials. And on the other hand, if the credentials are not rotated frequently enough, the threat of the dictionary attack is not mitigated.
A second concern is that the credentials tend to be stored, or cached for some period of time, on client C in such systems, exposing resources of server S to danger. Should a malicious hacker determine how to expose their existence on client C, the resources of server S become exposed. The problem compounds if the hacker shares the credentials with other users and devices. This risk remains whether the credentials are rotated or not, and whether it is a physical user or machine that is responsible for inputting the credentials for login. From the standpoint of server S, this is a problem because the security risks to its resources are no longer localized to the four corners of its storage.
Where trust is already established between the devices, however, there should be a way to hand out credentials to the client dynamically just before login for automatic login in a way that enables frequent rotation of the credentials and does not store the credentials on the client machine.
Thus, it would be desirable to have a way for logon credentials to be handed out over the network automatically, by the computer into which logging or access is sought, just before the login actually occurs. It would be desirable to have a way for an authentication exchange to ensue between two computing devices based on those credentials in a way that is not subject to the threat of a dictionary attack, or subject to local snooping of the client C's storage to extract credentials. It is further desirable to have a generic and simple mechanism or framework for a first device to securely declare or distribute a credential to a second device, over the same network over which the subsequent login exchange occurs.